Fixes up InverseDynamicsController to use the actuation matrix #22315
Conversation
RussTedrake
force-pushed
the
inv_dyn_controller_B
branch
from
2a598b3 to
a3998dc
Compare
Clarifies that the control output of the inverse dynamics controller is actuation, not generalized forces, and uses the actuation matrix to achieve this. Previously, by connecting the output of the InverseDynamicsController system to an actuation input port of the MultibodyPlant, we implicitly assumed that the actuator matrix was the identity matrix. If the actuators were in a different order than the joints (generalized forces), then our method produced the wrong actuator inputs. The generalized_force output port is still available, partly for backwards compatibility, and because it's possible that there are applications that prefer this. This is a rewrite of PR RobotLocomotion#20971.
RussTedrake
force-pushed
the
inv_dyn_controller_B
branch
from
a3998dc to
dada800
Compare
|
+@sherm1 for feature review, please? |
There was a problem hiding this comment.
I'm not an official reviewer. But caught a couple of things (that might not turn out to be real issues).
Reviewable status: 2 unresolved discussions, LGTM missing from assignee sherm1(platform), needs at least two assigned reviewers, missing label for release notes (waiting on @RussTedrake)
systems/controllers/inverse_dynamics_controller.h line 35 at r1 (raw file):
* inverse dynamics computation. * * @note In the case where the plant is not fully actuated, then B⁻¹ is
Docs currently states that "this class assumes the robot is fully actuated" [1, 2]. Is that not true anymore since we're now using an actuation matrix that need not be full rank? Or we do we still need to assume the plant is fully actuated, in which case this comment is redundant?
systems/controllers/test/inverse_dynamics_controller_test.cc line 76 at r1 (raw file):
robot_context == nullptr ? robot_plant.CreateDefaultContext() : robot_context->Clone(); VectorX<double> expected_force = controllers_test::ComputeTorque(
Is it weird that we have "force" on the left hand side, and "ComputeTorque" on the right hand side?
Clarifies that the control output of the inverse dynamics controller
is actuation, not generalized forces, and uses the actuation matrix to
achieve this. Previously, by connecting the output of the
InverseDynamicsController system to an actuation input port of the
MultibodyPlant, we implicitly assumed that the actuator matrix was the
identity matrix. If the actuators were in a different order than the
joints (generalized forces), then our method produced the wrong
actuator inputs.
The generalized_force output port is still available, partly for
backwards compatibility, and because it's possible that there are
applications that prefer this.
This is a rewrite of PR #20971.
+@sherm1 for feature review, please (as the reviewer of #20971)
cc @EricCousineau-TRI who was involved in the first PR.
cc @siddancha
Note: I will follow-up with changes to Anzu as needed.
This change is